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REMARKS 

This Amendment is responsive to the final Office Action mailed January 29, 2004 
and to the Advisory Action mailed April 9, 2004. Applicants respectfully submit that 
claims 1 , 3-9. 1 1-13, and 15-18 as set forth herein patentably distinguish over the cited 
references, and ask for allowance of these claims. 

The current status of the claims 

Claims 1, 3-9, 11-13, ar^d 15-18 stand rejected under 35 U.S.C. §102(©) as 
being anticipated by Ponnekanti et al. (U.S. 6,363,387, hereinafter "Ponnekanti"). 

THE PRESENT APPLICATION 

The present application addresses and overcomes certain deadlock situations 
created by concurrent transactions in a database having a unique key index. A 
deadlock condition may be created when, for example, two substantially simultaneous 
delete transactions involving different rows are followed up by two substantially 
simultaneous insert transactions that attempt to insert row data into the rows having the 
row identifications (RID's) of the deleted rows. 

In database systems utilizing pseudo-deletion of index entries, a deadlock 
situation can arise rf the two simultaneous insert transactions have index key values 
corresponding to the deleted rows. In this case, each insert transaction may acquire an 
X-lock for the pseudo-deleted index entry matching the other insert transaction's key 
value to enter data into that row. Each insert transaction will also attempt to acquire an 
S-lock on the pseudo-deleted row having index key value corresponding to the index 
key value of the Inserted data. This S-lock acquisition attempt is performed to verify that 
the pseudo-deleted row is actually deleted (that Is, the delete has committed), so that 
the inserted row will have a unique key value. Each S-lock becomes blocked by ttie 
X-lock of the other insert transaction, thus causing deadlock. 

The deadlock occurs because the system is unable to recognize that the 
blocking X-locks are not associated with the delete transactions, which have already 
committed. The present application overcomes this deadlock by providing: 

(1 ) a new X-lock attribute, called a "Delete" attribute logically associated with the 
X-lock, that is set when an X-lock Is granted to a Delete transaction; and 
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(2) a new Conditional S-Iock, tliat is: 

a. not compatible with an X-lock with the lock Delete attribute set; 

b. compatible with an X-lock with the Delete attribute NOT set. 
Specification at page 20 line 19 through page 21 line 4. 

The delete attribute element (1 ) is an attribute of a lock, and sen/es to distinguish 
the X-lock acquired by a delate operation fronni X-locks acquired by other types of 
operations. In FIGURES 4(B) and 4(C). the Delete element 450 appearing in the Lock 
Table is the new X-lock delete attribute. The delete X-lock attribute (that is. element (1 ) 
above) is different from the pseudo-delete flag, such as the pseudo-delete flag .412 
shown in FIGURES 4(B) and 4(C). 

The X-lock delete attribute is distinguished from the pseudo-delete flag attribute 
of an index entry , which appears as the symbol "D" In the Index Table. See at least at 
page 1 6 lines 7-12. The delete X-lock attribute disappears when the X-lock Is removed 
after the delete is committed; in contrast the pseudo-delete flag 412 remains set even 
after the delete is committed. 

The new Conditional S-lock is conditional with respect to the delete X-lock 
attribute, and is granted when there is no X-lock or when there is an X-lock but that lock 
does not con^espond to a delete operation (that is. the delete X-lock attribute is OFF). 
Thus, granting of the Conditional S-lock ensures that either there is no X-lock or, rf there 
is an X-lock, then that X-lock is not associated with a delete operation. 

As noted In the specification at the bottom of page 20, the new X-lock attribute, 
called a "Delete" attribute is provided- The Delete attribute is logically associated with 
an X-lock in a manner that, as described on page 20, the Delete attribute flag or other 
indicia is set when the X-!ock is granted to a Delete transaction. Further, a new 
Conditional S-lock is provided having specialized behavior relative to X-locks. The 
Conditional S-lock is not compatible with an X-lock whose Delete attribute flag is SET or 
ON. However, the Conditional S-lock is compatible with an X-lock whose Delete 
attribute flag is NOT SET or OFF. Essentially, the new Conditional X-lock is granted 
when the previous X-lock requestor was not a Delete operation. Thus, support is 
provided in the specification for the amendments made to the claims above wherein the 
Delete X-lock attribute is logically associated with an exclusive X-lock. 
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THE PONNEKANTI REFERENCE 

Ponnekanti does not disclose a delete X-lock attribute logically associated with 
an X-lock. 

Ponnekanti does disclose a delete bit for index entries: "Each \r\6ox row employs 
a ROW_DELETE bit." Ponnekanti col. 12 lines 58-64 (underscore added). This index 
ROW_DELETE bit conresponds to the pseudo-delete index entry attribute disclosed in 
the present application. The index ROW DELETE bit cannot simultaneously 
correspond to the X-lock delete attribute . 

Ponnekanti also discloses a data ROWDELETE bit. Ponnekanti col 12 lines 
34-37. The ROWDELETE status bit is associated with the row, and not with the X-lock 
obtained by the delete operation. This distinction is shown at col. 12 lines 36-57, which 
explain that a delete operation "sets the ROW_DELETE bit but the contents of the data 
row are left intact." Col, 12 lines 40-42. The ROW_DELETE status bit is reset when a 
subsequent transaction locks onto the row, at which time the row delete bit can be 
removed. Thus, the ROWDELETE status bit remains after the delete operation's X-lock 
is removed - it therefore cannot be associated the X-lock of the delete operation , 

This is further shown at Ponnekanti col. 1 3 lines 31 -51 , which describes the use 
of a "lock Instant." The "lock instant" appears to correspond to the unconditional S-lock 
of the present application^ and is used "to see whether there exists a conflicting lock 
already held on the row." CoL 13 lines 36-38, When a "delete" status bit is found, the 
"lock instant " is requested. If no conflicting lock is found, then the "lock instant" is 
granted and the operation issuing the "lock Instanr knows that the delete operation has 
been committed. Col. 1 3 lines 38-40, This further demonstrates that the delete bit is not 
a lock attribute - It may be that the delete bit is set even though there is no lock on the 
row. 

On the other hand, If a conflicting lock does exist, the "lock instant" fails, 
and is queued (I.e., sleeps) until the conflicting took is removed. Col, 13 lines 46-48. 
This is the nonnal operation of an unconditional S-lock when a conflicting X-lock is 
already applied. There is no disclosure or fair suggestion to provide a lock attribute of 
the X-lock to Identify whether the conflicting lock was issued by a delete operation. 
Without such an X-lock attribute, the system cannot tell whether an X-lock conflicting 
with the unconditional S-lock is due to a delete operation or some subsequent 
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operation, such as another insert operation. Two insert operations attempting 
substantially simultaneous S-locks can thus be deadlocked, and this deadlock is not 
overcome by Ponnekanti. 

As noted by the Office Action, Ponnekanti also uses the expression "conditional 
lock request." However, this conditional lock request is entirely different from the 
Conditional lock request disclosed in the present application. 

Ponnekanti defines an unconditional lock request and a conditional lock request 
In the case of an unconditional lock request that requests a lock on an already locked 
now, the unconditional lock request is queued (i.e., sleeps on the lock) until the other 
transaction releases its lock. Ponnekanti coL 1 1 lines 36-41 . In the case of a conditional 
lock request that requests a lock on an already locked row "the Lock Manager retums 
LOCK_DIDNTQUEUE status and does not grant the lock." Ponnekanti col. 1 1 lines 42- 
44. 

The "conditioner aspect of Ponnekanti's conditional lock request resides in 
v^ether or not the lock is granted. If a conflicting lock exists, the conditional lock is not 
granted. In contrast. Ponnekanti's unconditional lock request is always granted, 
although it may be queued until a conflicting lock releases. In contrast, the Conditional 
lock of the present application is conditioned on whetl^r a conflicting X-lock has its 
Delete attribute OFF. 

To summarize, Ponnekanti does not disclose the Dejete X-lock attribute of the 
present application, which identifies an X-lock as associated with a delete operation. 
Ponnekanti also does not disclose the Conditional S-lock of the present application that 
is granted if a conflicting X-lock has its X-lock delete attribute not set. As a result. 
Ponnekanti does not resolve the deadlock situation illustrated, for example, in 
FIGURES 3(A><3(F) of the present application, because the conditional S*lock of 
Ponnekanti cannot distinguish between an X-lock of a delete operation and an X-lock of 
another operation. 

Claims 1-6 patentably distinguish over the cited references 
Claim 1 has been amended to call for the exclusive X-lock to include a Delete 
loQicallv associated therewith, a SET state of the Delete X-lock attribute being indicative 
of a transaction holding the X-lock being a delete transaction, Claim 1 has been further 
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amended to incorporate the subject matter of canceled claim 2 directed toward the 

Conditional S-lock. Specifically, amended claim 1 calls for: 

an unconditional S-iock that enables shared access to the first 
table element and Is selectively assigned by the lock manager to the first 
table element only when the first table element is without an exclusive X- 
lock previously assigned thereto; and 

a conditional S-look that enables shared access to the first table 
element and is selectively assigned by the lock manager to the first table 
element only when the first table element is either without an exclusive X- 
lock previously assigned thereto or is without an exclusive X-lock having 
its Delete X-lock attribute SET assigned thereto. 

Although PonnekantI discloses conditional and unconditional S-locks, these elements 
are wholly different from what is called for In amended claim 1. In Ponnekanti, the 
"conditional" S-lock is conditional in that if an X-lock exists, the conditional S-lock is 
simply not granted. There is no disclosure In Ponnekanti of a Delete X-lock attribute, 
much less of a Conditional S-lock whose granting is conditioned upon either the 
absence of a conflicting X-lock or the absence of a conflicting X-lock having its Delete 
X'lock attribute SET. 

For at least these reasons, Applicants respectfully submit that claim 1 , as well as 
claims 3-6 that depend therefrom, as set forth herein are in condition for allowance and 
request an early indication of allowance of these claims. 

Claims 7-9 patentably distinguish over the cited references 
Claim 7 has been amended to call for requesting a Conditional S-lock on a table 
row indexed by the pseudo-deleted table index entry, said Conditional S-lock having 
compatibility characteristics respective to an X-lock: 

the Conditional S-lock not including compatible with 
an X-lock having a Delete attribute logically associated with 
the X-lock that is SET or ON, and 

the Conditional S-lock being compatible with an X-lock having a 
Delete attribute that is NOT SET or OFF. 
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Ponnekanti does not disclose a conditional S-lock having these 
characteristics. Rather, what Ponnekanti calls a conditional S-lock Is granted 
conditional upon whether there is any conflicting X-lock, not on the attributes of 
the conflicting X-lock. 

Claim 8 sets forth that step of receiving an Indication that the Conditional 
S-lock is granted includes the steps of: 

granting the Conditional S-lock conditional upon the table row indexed by the 
pseudo-deleted table index entry not having an X-lock assigned thereto; 

granting the Conditional S-lock conditional upon the table row indexed by the 
pseudo-deleted table index entry having an X-lock assigned thereto wherein said X-lock 
has its Delete attribute not set, reset, or off] and 

receiving an indication that the Conditional S-lock is granted conditional upon the 
granting of the Conditional S-lock. 

Claim 8 specifies that the Conditional S-lock is granted in the case where the 
X-lock assigned thereto has its Delete attribute not set, reset, or off. In contrast, 
neither the conditional nor the unconditional S-lock of Ponnekanti is ever granted 
when an X-lock is also present . In the conditional case, a conflicting X-lock in 
Ponnekanti simply causes the conditional S-lock to fail> whereas in the unconditional 
case a conflicting X-lock in Ponnekanti causes the S-lock to be queued (or to 
"sleep," as Ponnekanti puts it). 

For at least these reasons, Applicants respectfully submit that claims 7-9 as set 
forth herein are in condition for allowance and request an early indication of allowance 
of these claims. 

Claims 11-13 patentably distinguish over the cited references 
Claim 11 has been amended to call for requesting a Conditional S-lock on a 
table row Indexed by the pseudo-deleted table index entry, said Conditional S-lock 
being Incompatible with an X-lock acquired by a delete operation and being 
compatible with an X-lock not acquired by a delete operation based on a Delete 
attribute logically associated with the X-lock . The conditional S-lock of Ponnekanti 
does not distinguish between an X-lock acquired by a delete operation and an 
X-lock not acquired by a delete operation. As a result, under certain circumstances 
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the database of Ponnekanti can experience deadlock if an S-Iock applied to verify 
that a delete operation has committed is blocked by an X-!ock applied by an 
operation other than the Delete operation. In contrast, by using the Conditional 
S-lock as called for in claim 1 1 such a deadlock does not arise, because the 
Conditional S-lock recognizes that the conflicting X-lock was not acquired by a 
delete operation. Hence, the delete operation must have committed, and so the 
Conditional S-lock is granted. 

Claim 12 further distinguishes over Ponnekanti, which does not disclose orfairiy 
suggest granting the Conditional S-lock conditional upon the table row indexed by the 
pseudo-deleted table index entry having an X-lock assigned thereto wherein said X-lock 
has a Delete attribute that Is not set, reset, or off. as called for In claim 12. 

For at least these reasons, Applicants respectfully submit that claims 11-13 as 
set forth herein arc in condition for allowance and request an eariy indication of 
allowance of these claims. 

Claims 15-18 patentabty distinguish over the cited references 
Claim 15 calls for a lock manager for use in a database management system 
(DBMS) managing a database application including a database having at least one 
table and cooperative with an index manager and a data manager for restricting 
access to a first table element of said at least one table by assigning one or more 
locks thereto including at least an exclusive X-lock that enables exclusive access to 
the firat table element the exclusive X-lock including a Delete attribute lo gi p^ Hy 
associated therewith, a SET state of the Delete attribute being indicative of a 
transaction holding the X-lock being a delete transaction. 

Ponnekanti does not disclose an exclusive X-lock including a Delete attribute 
logically associated therewith in which a SET state of the Delete attribute Is 
indicative of a transaction holding the X-lock being a delete transaction. By Including 
a delete X-lock attribute as called for in claim 15, a subsequent insert transaction 
can determine whether or not an X-lock on a pseudo-deleted row means that the 
delete transaction has not yet committed. 

Claim 16 calls for the lock manager to be adapted to restrict access to said 
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first table element by assigning a Conditional S-lock that enables shared access to 
the first table element and is selectively assigned by the lock manager to the first 
table element only when the first table element does not have an X-lock with its 
Delete attribute In a SET state assigned thereto. Ponnekanti does not disclose a 
Conditional S-lock with the behavior called for in claim 16. 

Claim 18 calls for the lock manager to be operative to grant the Conditional S- 
lock on the table row corresponding to the existing Index key entry only when the table 
row is without an exclusive X-lock assigned thereto, or the table row has an exclusive 
X-lock assigned thereto with its Delete attribute not in said SET state, to enable the 
index manager to update the table index key entry with the new row identification RID, 
release the Conditional S-lock on the table row corresponding to the existing index key 
entry, and reset the pseudo-delete flag to and OFF state. Ponnekanti does not disclose 
granting a conditional S-lock when the table row has an exclusive X-lock assigned 
thereto with its Delete attribute not in said SET state. Indeed, Ponnekanti does not 
disclose a Delete attribute of an exclusive X-lock. 

Comments on Advisory Action : 

It is to be noted that the proposed amendments contained in the First 
Amendment After Final Rejection filed on March 29, 2004 were not entered into this 
application. More particularly, as indicated in the Advisory Action mailed April 9, 2004, 
the Examiner noted that the proposed amendments "raise new issues that would 
require further consideration and/or search" and that "they are not deemed to place the 
application in better form for appeal by materially reducing or simplifying the issues for 
appeal'* as indicated on the form PTOL-303- 

On page 2 of the Advisory Action, the Examiner indicated partlculariy that the 
new issue is that "the Delete X-lock attribute is 'logically' associated with an X-lock," 

Applicants respectfully submit that the amendments tendered to independent 
claims 1, 7, 11, and 15 do not raise new issues. By way of example, claim 1 was 
amended to more particularty point out and clarify that the Delete X-lock attribute is 
logically associated with an exclusive X-lock. In claim 1, claim language in the sub- 
paragraph directed to the conditional S-lock states that an exclusive X-lock can have its 
Delete X-lock attribute SET. 



Page 16 of 18 

PAGE IS/20 ' RCVD AT 4/29/2004 5:01 :21 PM [Eastern Daylight rime] ' SVR:USPT0{FXRF-1/3 ' DNiS:8729306 ' CSID:216 241 1666 * DURATION (mm-ss):0544 



Apr. 29. 2004 5:06P^WFay SharPe ^ No. 0853 P. 19 

Application No. 09/894,090 
' Amendment Dated April 29, 2004 

Reply to OfTtce Action of January 29, 2004 and Advisory Action of April 9, 2004 



This language was present In claim 1 prior to the First Amendment After Final 
Rejection. The word "its" is the possessive fomn of the word "It" and, accordingly, as 
written, the exclusive X-lock "possesses" a Delete X-lock attribute according to the 
dictionary definition of "its" In its normal usage. In addition to this, the specification of 
the present invention describes the Delete X-lock as being logically associated with the 
exclusive X-lock type. 

According to the above, therefore, the addition of the language of the exclusive 
X-lock including a Delete X-lock attribute logically associated therewith was already or 
previously effectively contained in the claims by the language In at least the last two 
lines of claim 1 whereat it is described that an exclusive X-lock can have its Delete X- 
lock attribute SET. The Delete X-Iock attribute is, in effect, possessed by the exclusive 
X-lock type and, to that extent, is logically associated with the X-lock. 

Therefore, respectfully, applicants respectfully submit that the amendments 
tendered to independent claims 1, 7, 11, and 15 in the First Amendment After Final 
Rejection and repeated in this Second Amendment After Final Rejection, raise no new 
issues and will require no further consideration and/or search. 
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CONCLUSION 

For the reasons set forth above, it is submitted that all claims 1, 3-9. 11-13, and 
15-18 as set forth herein patentably distinguish over the references of record. 
Allowance of all claims and an early notice to that effect Is respectfully requested. 



Respectfully submitted. 
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